ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group98b.txt/000066_icon-group-sender _Thu Jun 4 12:30:25 1998.msg

Internet Message Format | 2000-09-20 | 6KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id MAA06878
    for <[e-mail]>; Thu, 4 Jun 1998 12:30:25 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA12324; Thu, 4 Jun 1998 12:30:18 -0700
From: "Nevin :-] Liber" <[e-mail]>
To: <[e-mail]>
Subject: Re: Directory access facilities
Date: Thu, 4 Jun 1998 12:47:30 -0500
Message-Id: <01bd8fe0$d860a2e0$c37546cf@NEVIN>
Mime-Version: 1.0
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3
Errors-To: [e-mail]
Status: RO
Content-Length: 5285

-----Original Message-----
From: Richard A. O'Keefe <[e-mail]>
To: [e-mail] <[e-mail]>;
[e-mail] <[e-mail]>
Date: Thursday, June 04, 1998 10:11 AM
Subject: Re: Directory access facilities


Let me preface this by saying that I know very little about Tcl/Tk;
basically, playing around with "tclsh" and checking out the man pages at
<http://cuiwww.unige.ch/eao/www/TclTkMan/Man.html>.

>I'd like to say that people seem to have missed the point of my reference
>to Tcl/Tk.  The point is that there is an *existing* *multiplatform*
>implementation of this idea that *works*.  We don't have to design.
>We can steal.

If it is the appropriate abstractions for the language at hand.  I don't
believe it is.

>The *last* thing we have any shadow of an excuse for doing is bodging
>together yet another incompatible design by appealing to "preferences".

My "preferences" come from using the language for the last 14 years, and I
suspect that Gregg Townsend has been using it even longer than I have.  I
think I have a pretty good sense of what fits in the language and what
doesn't.

It appears that Tcl/Tk is a language where everything is a string.  For
instance, "glob" returns a string of encoded filenames; one has to encode
some the filenames, because they may contain embedded seperators, embedded
encoding characters, etc.

In a shell this works, since a shell parses each and every command line, and
provides facilities for dividing a delimiter-seperated string into seperate
strings.

Icon does not do this, nor does it have builtin facilities for "unquoting"
an encoded filename.  In order to use this, there would have to be a
higher-level function that breaks up the string, gets rid of any quoting
characters that aren't part of the filename, and either returns a list of,
or more likely, generate a list of filenames.  Considering the lower level
system already keeps filenames as seperate entities, it seems that we are
doing a lot of work for nothing.

Now, one might argue that "glob" allows regular expressions for filtering.
However, regular expressions aren't used anywhere else in Icon; it would
look like a wart on the language.

What I am looking for is minimal functionality that will get me the
filenames broken up one filename at a time, since it is easy to build the
more complex stuff on top of that from within Icon.  Gregg's suggestion of a
generator that does just that meets that criterion nicely.

>But where did you get the idea that the presence of "." and ".." was 'an
>accurate representation of what is in the directory'?  There are POSIX
>implementations that go to some trouble to fake these entries because the
>_real_ directory format _doesn't_ have them.

And on "real" systems, "." and ".." don't necessarily do what you expect.
For instance, most shells interpret them differently.  Do a "cd
/foo/bar/../baz", and the shell would put you in "/foo/baz", yet if you
actually traversed the directories, you could be in "/baz", if "/foo/bar"
was a symbolic link to "/", for instance.  It's hard to encapsulate all of
this functionality without providing a full filesystem API.

Whatever the lower-level C functions return is what the Icon equivalent
should generate.


>To the best of my knowledge there isn't any Icon implementation for that
>machine, but there's a standard C compiler and a near-enough-to-POSIX
>OS interface, so there _could_ be an Icon implementation.

I don't believe POSIX is a requirement of Icon right now.


>As I've hinted above, we could
>patch around this particular problem by insisting that directory names
>always end with a (native) separator and file names not

But nothing else in Icon follows this convention.  Strings don't have
special embedded terminators; lists don't have special embedded terminators,
etc.  If you add a seperator or directory marker, you have to add a way of
quoting the seperator or directory marker (since a file name might
legitimately end with the directory marker) and functions to remove the
quotes.  This is much messier than having a generator suspend filenames one
at a time, and a seperate function to test if it is a directory.  Also, what
if you are creating a directory name somewhere else in your program?  You
have to have a function that turns a string into a directory name.

To use EE terms, I much prefer out-of-band signaling to in-band signaling.
Since we can get filenames already seperated (out-of-band signaling, since
something outside of the string itself indicates that this object represents
a directory), it is cleaner than having to parse a string (in-band
signaling, since whether or not it is a directory is encoded in the string)
when I just want to get the filename out of it.

Now, I do understand your point about systems where directories are in
seperate namespaces.  The cleanest solution would be to have two seperate
generators; one which returns regular files, and one which returns
directories.  I don't know if this is worth the effort, since so few systems
out there have seperate namespaces.
__
 Nevin ":-)" Liber  <mailto:[e-mail]>  [phone]
  Senior Software Engineer, Pendragon Software <http://www.webfayre.com/>